前面幾篇文章我們大部份都是在討論 :

集中式架構如何的分層

但應該有不少人注意到，我們是專注在每一層的『 技術 』分層該做什麼事情，要處理畫面的就丟到 Presentation Layer，要處理業務邏輯的就丟到 Domain Layer，而要處理資料的就去 DataSource Layer，這個前期還可以，但過了一段時間就會變的如下圖一樣，每一層都非常的肥大，尤其是新創企業前期為了追求快速。

基本上會面臨的問題為 :

• 可能一個 repository ( 放程式碼的地方 )，有 5 個團隊一起在使用，每天解 conflict 就飽了。
• CI/CD 的時間拉的非常久。
• 有的團隊的業務 QPS 就是很高，有的很小，這樣整個擴展性會有問題，也會浪費不少錢。
• 多個團隊有可能會有不同的撰寫風格，有機率會進入混沌時代。
• QE 與 QA 測試難度增加，因為你想想假設 QE 在某個測式環境進行測試中，結果另一個團隊又進程式碼了，那 QE 基本上一定只能重測，因為不能保證進的不會影響；如果規定時間才能進，那代表整個 deploy 時間會變很長，因為要排隊；開多個測試環境，但問題在於，一定要有個環境是測所有團隊程式碼合併後的地方。

所以之後就會往下圖這個方向前進，也就是所謂的 :

微服務

困難點

要往微服務這個方向前進的人們，應該都有面臨的到的問題那就是 :

怎麼切 ?

對 ~ 就是要怎麼切 ? 要用什麼單位來切 ? 那假設我們的 domain layer 都是混在一起，要怎麼辦呢 ?

DDD Domain-Driven Design 的誕生

Eric Evans 在 2003 年發表了 Domain-Driven Design: Tackling Complexity in the Heart of Software 這本書，書中提出了 :

以業務視角出發，來建構出軟體架構

那 DDD 和我們上面提到的難題有什麼關係呢 ?

DDD 就是可以幫助我們建立一個，好切的架構。

接下來會有幾篇文章，我們會來討論它的架構於 :

• 戰略 : 如何切
• 戰術 : DDD 分層架構

單體式如何到微服務

不過這裡要說一下，如果你的最一開始就是以 DDD 來進行專案開發，那恭喜你，你們未來要切成微服務應該沒有到太困難，但如果你們是很大包噁心的集中式要切微服務，呃…… 我現在還不知道怎麼解，因為我現在也碰到這個問題。

目前我們在看《單體式系統到微服務 (Monolith to Microservices)-Sam Newman 》這本書，書中有提到幾個建議，我在這裡記錄一下 :

• 重新單體式系統 : 組織現有的整體架構，讓未來好切分，書中強烈推薦《 Working Effectively with Legacy Code : 管理、修改、重構遺留程式碼的藝術 (中文版) - Michael Feathers 》，其中『 縫隙 』的概念最重要，不過這本我沒看過，所以不知道是啥。
• 模組化單體式 : 就是將一些東西 libary 化，作者認為這是最好的方法。但我自已覺得問題會與切微服務的問題一樣，『 要以什麼單位來切 libary 呢 』?
• 漸進重寫 : 作者傾向『 先挽救現有程式碼 』然後再重新實現功能。然後他還發現很多團隊會有新功能時就新創建微服務，但問題在於你新創建的微服務，能避免之前發生的問題嗎 ?

這後有空在來開一篇，來寫寫書中裡所提到的分割方法。

小總結

這篇文章簡單的談談，我們之前的 3-Tier 又可以稱為集中式架構，所面臨到最大的問題 :

太大了，不知道如何切，怎麼切都會有混在一起的業務邏輯

而 DDD 的誕生就是教我們如何設計出一個『 好切的架構 』，但這不代表我們前面提到的那些都不重要，因為那些東西的概念仍然會在 DDD 裡面有使用到。

軟體架構也是有一張地圖。

接下來我們將會開始往 DDD 研究。